3. Security Token Authentication
The custom
authorization policy (or any authorization policy) is built to add
claims to the security context for the request. However, this is not
the only place where claims are added. When a request first arrives at
the service, the security tokens included with the request are
evaluated. These claims are also added to the security context.
The process of actually interpreting the token and adding the claims is left to a set of classes known as Token Authenticators. There is a separate authenticator for each type of token. Table 3 contains a list of the most commonly used token authenticators.
Table 3. Commonly Used Security Token Authenticators
SecurityTokenAuthenticator Type | Description |
---|
WindowsSecurityTokenAuthenticator | Ensures that the token is a valid Windows token. A WindowsClaimSet is generated. |
KerberosSecurityTokenAuthenticator | Ensures that the token is a valid Kerberos token. A WindowsClaimsSet is generated. |
X509SecurityTokenAuthenticator | Validates the certificate. If possible, the certificate is mapped to a Windows identity. An X509ClaimSet is generated. A WindowsClaimSet is generated if the identity mapping was successful. |
WindowsUserNameSecurityTokenAuthenticator | Creates a Windows token for the username and password provided. A WindowsClaimSet is generated. |
CustomUserNameSecurityTokenAuthenticator | Validates the username and password against the configured membership provider or password validator. A UserNameClaimSet is generated. |
SamlSecurityTokenAuthenticator | Ensures that the SAML token is valid. Includes the claims that are part of the token in the security context. |
Because
a single request can contain more than one token, it is possible that
more than one authenticator will be used for the same request. Also,
the data store used for authentication depends on the type of token.
Windows tokens are authenticated against the Windows domain, as are
username tokens, unless another provider has been specified. To change
the provider for username tokens, change the userNamePasswordValidationMode attribute from Windows to MembershipProvider. This causes the ASP.NET membership provider to be used. Alternate membership providers can be specified in a single userNameAuthentication element. The following segment illustrates the attributes available to this element:
<userNameAuthentication
cacheLogonTokenLifetime="<TimeSpan>"
cacheLogonTokens="<Boolean>"
customUserNamePasswordValidatorType="<String>"
includeWindowsGroups="<Boolean>"
maxCacheLogonTokens="<Integer>"
membershipProviderName="<String>"
userNamePasswordValidationMode="<Windows|MembershipProvider|Custom>" />
A number of attributes are directly related to caching the tokens. The cacheLogonTokenLifetime attribute specifies how long any individual token should be cached. The maxCacheLogonTokens attribute indicates how many tokens should be kept in the cache at one time. Caching tokens is controlled through the cacheLogonTokens
attribute. If tokens are cached, the claim set generated by the token
is stored so that if the token is presented again, the cache claims can
be added without having to go back to the security data store.
The includeWindowsGroups
attribute determines whether the Windows groups to which a user belongs
should be included in the generated claim set. If this attribute is set
to true,
there is a potential performance implication because all the Windows
groups will be expanded to ensure that all the appropriate groups are
included in the claims.
The last three attributes are related to how the username token is authenticated. If the userNamePasswordValidationMode is set to MembershipProvider, the membership provider specified in the membershipProviderName attribute validates the credentials. If the userNamePasswordValidationMode is set to Custom, the password validator identified by the customUserNamePasswordValidatorType attribute authenticates the credentials.
Certificates are authenticated using the rules specified in the clientCertificate section of the service behavior. There are two components in the clientCertificatecertificate
element specifies which certificate to use when secure communication
with the client must be arranged. This would normally be required when
a secure duplex channel is used and is not part of the authorization
process. configuration. The
The second component is the authentication
element. This element specifies how the certificate should be
authenticated. The following segment illustrates the options that are
available:
<authentication
customCertificateValidatorType="<typeName>"
certificateValidationMode="<validationMode>"
includeWindowsGroups="<Boolean>"
mapClientCertificateToWindowsAccount="<Boolean>"
revocationMode="<NoCheck|Online|Offline>"
trustedStoreLocation="<CurrentUser|LocalMachine>" />
Notice the includeWindowsGroups
attribute. The value of this attribute determines whether groups are
included in the generated claim set. This is the same function as is
found in the userNameAuthentication element.
There are three types of validation modes. If certificateValidationMode is set to Custom, the type indicated by the customerCertificateValidatorType attribute validates the certificate. If the validation mode is set to ChainTrust, the client certificate is validated against the root certificate on the service’s computer. A validation mode of PeerTrust
ensures that the public key portion of the certificate is in the
Trusted People certificate store on the service’s computer. It is also
possible to set the validation mode to ChainOrPeerTrust, which simply applies an OR to the previous two descriptions.
As part of the certificate validation, it is possible to use the trustedStoreLocation attribute to indicate where peer trust looks for the public keys. The options for this attribute are either CurrentUser or LocalMachine.
The last attribute associated with the authentication element is the revocationMode. There is a certificate revocation list, which is a list of certificates that are no longer considered to be valid. The revocationMode attribute indicates whether and when the incoming certificates should be checked against this list. If the value is set to NoCheck, no check is performed. If the value is set to Online, the certificate will be checked with every request. When set to Offline, the certificate will be verified against a cached list of revoked certificates.